Flash Memory in an Educational Environment

Commercial applications of embedded systems often use flash memory so vendors can update software in customer-owned systems without physically removing and replacing ROM chips. These reflashing operations are safe because they occur under tightly controlled conditions involving updates with thoroughly validated software. We have developed a reflashing mechanism that is far more flexible and far more robust than previously existing approaches. Besides being suitable for commercial environments, our approach also supports the considerably more stringent needs of a university program for students in computer engineering. We allow a student to reflash the memory in a microcontroller system and take over the entire system, including the reset vector. Students can therefore test their own system software. A student’s experimental software may contain errors, of course, but our reflashing approach provides a simple, convenient, and foolproof mechanism for recovering and installing the latest version of our validated system software even if the student’s system software crashes immediately after a reset. 1 Background and Environment At Arizona State University, students in Computer Science and Engineering use a variety of microprocessor and microcontroller development stations at several levels in the curriculum. They initially use development stations in a beginning class to learn about programming in assembly language, and they later use the stations in different ways in subsequent classes to learn about the details of system software, digital hardware design, and hardware/software interfaces. Each station in our lab includes a PC and several different custom-designed microprocessor and microcontroller target platforms. The PC provides network access to allow students to edit, assemble, and link on a host server, and the PC communicates with the target platforms through serial ports in a daisy-chain arrangement. The multiple target platforms allow us to support multiple courses at various levels of student experience since each target platform has its own particular type of microprocessor or microcontroller and its own unique hardware design. Each microprocessor or microcontroller in our lab runs a common operating system and debugger known as MUDBUG [1] (for Monitor-Utility-DeBUGger). We originally developed the first version of MUDBUG back in 1975, and we have made extensive upgrades over the years since then. MUDBUG employs conditional assembly to support a number of target systems with various processors. Students who take our senior-level course in Systems Programming gain practical experience by making modifications to MUDBUG, so we continue to enhance MUDBUG at frequent intervals. 2 Challenge of Updating MUDBUG Until recently, our design of a microprocessor or microcontroller target platform typically used an EPROM to contain MUDBUG. The idea was that we could conveniently update MUDBUG once a year or perhaps once a semester by erasing and reprogramming each platform’s EPROM. This approach worked well in the early years, but removing, erasing, reprogramming, and reinserting EPROMs became increasingly cumbersome as the lab grew to include more than 40 development stations with four or five different target platforms at each development station. An obvious solution was to migrate from EPROMs to flash memory. With flash we could update MUDBUG in the circuit in a matter of seconds without even opening the chassis that contains the platform. Many embedded systems in the commercial world use flash memory so technicians can update software for customers. We wanted to go considerably beyond that level, however. First, we wanted students to be able to flash their own experimental versions of MUDBUG or any other operating system into the target platforms, taking over the reset vector and the entire memory image in the process. Second, knowing that experimental student programs often fail to work, we wanted a foolproof method that would allow even a beginning student to restore a working version of MUDBUG to a target platform quickly, easily, and automatically no matter how badly someone’s experimental operating system had crippled the platform. The flash-programming mechanisms that commercial systems employ are not nearly robust enough for our use. A trained technician reflashes a commercial system with thoroughly tested, released software. In our case, we want to allow students (who are just learning and may be prone to mistakes) to reflash our target platforms with software that may not work at all or perhaps even with software that is malicious. In any event, we want to allow the student to take over the reset vector and have complete control of the system starting at power-up time. In spite of letting the student take complete control, we want to provide a simple, convenient, and foolproof mechanism for recovering and installing the latest version of MUDBUG regardless of what the student’s software does. 3 Commercial Approaches How do commercial systems update flash memory? The most common approach involves putting kernel software into a boot block and locking that boot block to make the kernel permanent. Under normal operating conditions, the kernel transfers control to the system’s application software following a reset. Under some sort of special condition, however, the kernel retains control and provides a feature for reflashing the rest of the flash memory with updated software. For example, the kernel might check a port for a special input during the first two seconds following a reset, and that input could activate the kernel’s reflashing feature. One disadvantage of the kernel approach is that the kernel can never change since the boot block is permanently locked. The kernel must anticipate all future needs and must handle all future communication protocols for receiving a new image for the flash memory. Also, the application software cannot receive control immediately after a reset if the kernel watches for a special input during the two seconds following a reset. Many microcontrollers allow the software to configure the hardware only during a fixed number of clock cycles following a reset, so the kernel must perform these configuration steps. Unfortunately, the configuration can never change in the future since the boot block that contains the kernel is permanently locked. In our environment, we want the students to be able to take control immediately after a reset so they can configure hardware items that are configurable only during the few clock cycles following a reset. The development team for the GPDAS and VBI projects at General Motors [2] has developed a reflashing approach that is much more flexible than the kernel approach. They don’t lock the boot block or depend on a permanent kernel. Instead, they provide a simple but powerful load-and-go feature in their application software. With the load-and-go feature, they can load a program into RAM and then transfer control to that program. This feature allows them to load and run a program that reads a new image and reflashes the flash memory. They are not limited to any particular protocol since they simply load and execute a program that uses their current protocol. The drawback to the load-and-go approach is that a mistake in the new flash image can be catastrophic. If the new flash image doesn’t work well enough to provide at least the load-and-go feature, then the system is broken. In this case, someone must remove the flash memory chip from the system and reflash it in a flash programmer. Of course, the GM team exercises due diligence to make sure a new flash image works properly before sending it to the field. 4 The FlashBUG Approach In our educational application, we need the total flexibility of GM’s load-and-go approach, but we also need complete safety. We want the students to be able to reflash the entire image and take over the reset vector, so we need the complete flexibility that GM’s approach offers. However, GM’s load-and-go approach isn’t viable for us because we know the students are very likely to reflash a system with experimental software that doesn’t work at all. We must have a simple, convenient method of recovering and installing the latest version of MUDBUG even if the student’s flash image crashes immediately after a reset. We designed our hardware to provide a special reflash mode as well as a normal mode. Part of our flash memory contains the FlashBUG software that performs the reflashing function, and the rest of the flash memory contains MUDBUG or any experimental system software that a student flashes into memory. In the normal mode, the FlashBUG portion of the flash memory is not even in the processor’s memory map, so that memory effectively doesn’t exist at all. Meanwhile, the hardware prohibits writes to flash memory in the normal mode, so the system is absolutely secure in the normal mode. The system comes up in the normal mode following an ordinary reset. A student activates the special reflash mode by pressing the reset button and also pressing another button (the NMI button) while holding down the reset button. The hardware then maps the FlashBUG portion of the flash memory into the processor’s memory map, and the processor fetches FlashBUG’s reset vector and consequently runs FlashBUG. The rest of the flash memory moves to another part of the processor’s memory map in reflash mode, and the hardware allows write access to the flash memory. FlashBUG can therefore download any desired memory image and can flash it into the MUDBUG portion of the flash memory. FlashBUG allows the user to download a new flash image with FTP from any system that has an internet connection. A student can therefore download a flash image from almost any system anywhere in the world (perhaps from the student’s own home PC). Similarly, we can restore MUDBUG from anywhere in the world as long as we have an internet connection. After completing the reflash operation, FlashBUG switches the system back to the normal mode. At that point, the processor begins executing the new normal-mode software, and FlashBUG disappears from the memory map. At the same time, the hardware removes write access to the flash memory, thus making the system completely secure. 5 FlashBUG’s User Interface When a user activates the system in reflash mode, FlashBUG takes over the reset vector and comes up in place of MUDBUG. FlashBUG starts by copying itself into RAM and then executing from RAM for reasons that we’ll discuss later. FlashBUG uses a checksum to validate the current MUDBUG image in the flash memory and tells the user whether MUDBUG is valid or not. In either case, FlashBUG initiates a download procedure that allows the user to download either the current version of MUDBUG or any other alternative or experimental operating system that the user wants to program into the flash memory. A download window pops up on the screen of the PC to allow the user to specify the file to download to the flash memory. The student can have a change of heart, of course, and cancel the download by clicking the cancel button on the screen. The download window specifies the current version of MUDBUG as the default file to load, so a beginning student can conveniently accept the default to restore (or update) a system to the current working software. Alternatively, the user can specify any object file on any internetaccessible node as long as the user provides a valid username and password for that node. If FlashBUG doesn’t receive an object file within a reasonable amount of time, the system reports a failure and does not update the flash memory. This timeout mechanism protects against internet failures, host failures, and students who start updates and fail to complete them. Upon receiving an object file, FlashBUG downloads the file, checksumming each object record of the file to validate it, and FlashBUG programs the object image into the flash memory. The FlashBUG software validates download target addresses, of course, and disallows writes to the portion of the flash memory that contains FlashBUG, so FlashBUG itself remains secure. After the download and flashing operations are complete, FlashBUG computes a checksum for MUDBUG (or for whatever program the student downloaded) and saves that checksum in the FlashBUG portion of the flash memory for validation the next time someone activates the system in reflash mode. Then FlashBUG displays a message directing the user to press the reset button, removes its own portion of the flash memory from the memory map, and waits for the user to press the reset button to activate the new software in the MUDBUG portion of the flash memory. 6 Why FlashBUG Runs from RAM Why does FlashBUG copy itself from flash memory into RAM and then run from RAM? Running from RAM is necessary because FlashBUG resides in the same physical flash chip that contains the MUDBUG image. When we program the flash memory, the chip goes into programming mode until its internal programming operation is complete. We must be able to determine when the chip finishes its programming operation, of course, because the flash chip can’t function normally while it is in programming mode. As long as the flash chip is in programming mode, each read from any address in the chip results in a data value that has bit six toggled from the bit-six value of the previous read from the chip. When we read a flash location and get the same value for bit six two times in a row, we know the flash chip has finished its programming operation. With bit six toggling from one read to the next, we obviously can’t fetch instructions and correctly execute a program from the flash memory. Therefore, FlashBUG must copy itself into RAM and run from RAM before starting any programming operation. A more subtle consideration is that FlashBUG cannot use interrupts because the interrupt vectors are in the flash memory. An interrupt that occurred while the flash chip was toggling bit six would cause a severe failure. The user can induce such a failure, of course, by pressing the NMI button during a programming operation, but only the current programming operation fails. FlashBUG comes up properly the next time someone activates the system in reflash mode. 7 FlashBUG Advantages Our hardware design doesn’t even map FlashBUG into the processor’s memory map unless someone starts the system in reflash mode, so FlashBUG doesn’t consume any space at all in the memory map. This approach makes the entire memory map available for MUDBUG or for the student’s operating system. In effect, FlashBUG doesn’t even exist in the machine unless the system is in reflash mode. FlashBUG is therefore totally transparent to MUDBUG. Another elegant aspect of our hardware design is the fact that we use just one flash chip for both MUDBUG and FlashBUG. Instead of using an auxiliary EPROM or an auxiliary flash chip for FlashBUG, we put FlashBUG into the same flash chip with MUDBUG and use decoding logic to map various parts of that flash chip into the processor’s memory map. Actually, our sharing of the flash chip goes even further. We provide two processors, a 6800 and a 6809, on our target platform with a toggle switch that the student can use to select one processor or the other. Our single flash chip contains four sections: MUDBUG for the 6800, FlashBUG for the 6800, MUDBUG for the 6809, and FlashBUG for the 6809. Everything that we’ve described works the same way for both the 6800 and the 6809. Having two processors on a single platform allows us to support two different classes of students while sharing the chassis, the power supply, and 90% of the platform hardware between the two processors.